System and method for obtaining prequalification information

ABSTRACT

The system described herein provides a secure unified system for users to get prequalified for a loan based on a link provided by a seller. The link may include seller identification information. A user can use a user device to launch a website by actuating a link. The user device may receive input corresponding to the user&#39;s personal information on the website. The user may transmit a prequalification request using the website, to a central system. The central system may generate prequalification results. The central system may ensure the pricing structures generated for a given product are consistent with the generated prequalification results within a specified time period.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of Provisional Application No.62/852,202, filed on May 23, 2019, the contents of which are herebyincorporated by reference in their entirety.

BACKGROUND

Users often use web-based applications to apply for applying for loans.The web-based applications may provide results of their loan applicationto the user. However, it may be difficult for users to share the resultswith a person who is using a different web-based application inreal-time. In the event, a user needs to share such information with adifferent user who does not have access to the same web-basedapplication, the user may have to provide sensitive information aboutthemselves or may have to re-apply for the loan using the web-basedapplication used by the different user. This can create an added burdenon computer resources as well as a security risk of having to sharesensitive information.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and form a partof the specification, illustrate the embodiments of the presentdisclosure, and together with the description, further serve to explainthe principles of the embodiments and enable a person skilled in thepertinent art to make and use the embodiments, individually, or as acombination thereof.

FIG. 1 is a block diagram of an example network environment according tosome embodiments.

FIG. 2 is a block diagram of an example architecture according to someembodiments.

FIG. 3 is a block diagram illustrating an expanded view of examplemicro-services according to some embodiments.

FIGS. 4A-4D illustrate screens displayed on a graphical user interfaceof a user device to obtain prequalification results according to someembodiments.

FIG. 5 is a screen displayed on a graphical user interface of a sellerdevice according to some embodiments.

FIG. 6 is a flowchart illustrating the process of obtainingprequalification results according to some embodiments.

FIG. 7 is a block diagram of example components of a computing systemaccording to an embodiment.

In the drawings, like reference numbers generally indicate identical orsimilar elements. Additionally, generally, the left-most digit(s) of areference number identifies the drawing in which the reference numberfirst appears.

DETAILED DESCRIPTION

Provided herein are system, apparatus, device, method and/or computerprogram product embodiments, and/or combinations and sub-combinationsthereof, obtaining prequalification information using a provided link.

The system described herein provides a secure unified system for usersto get prequalified for a loan with one or more financial institutionsbased on a link provided by a seller at a seller location. The link mayinclude seller identification information. A user can use a personaluser device to launch a website or web application associated with thefinancial institution by actuating the link. The link may be actuatedbased on a scan of a computer-readable indicia, such as a barcode or QRcode, for example. The user device may receive input corresponding tothe user's personal information on the website. The user may transmit aprequalification request using the website, to a central systemassociated with a financial institution or a platform that may beconfigured to provide pre-qualification results for a plurality offinancial institutions. The prequalification request may include theuser information and seller identification information. The centralsystem may identify the seller based on the seller identificationinformation. The central system may process the prequalificationrequest, generate prequalification results for one or more financialinstitutions, and route the prequalification results to a seller devicebased on identifying the seller, or otherwise enable the seller toaccess the prequalification results via a seller portal. Theprequalification results may also be provided to the user in aninterface of the user's device. The central system may store theprequalification results in a prequalification database.

The seller device may transmit pricing requests for various products forthe user, to the central system. The central system may retrieve theprequalification requests from the prequalification database and processthe pricing requests based on the prequalification requests. The centralsystem may generate pricing structures for each of the various productsand transmit the pricing structures to the seller device. The centralsystem may store the pricing structures in a pricing database. Thepricing structures may be correlated to the user in the pricingdatabase. The seller device may transmit a purchase request of aparticular product for the user to the central system. The centralsystem may determine whether the particular product has been priced at aprior time by querying the pricing database. In response to determiningthe particular product has been priced at a prior time, the centralsystem may retrieve the pricing structure generated for the particularproduct and generate a new pricing structure for the product to bepurchased by the user, based on the previously generated pricingstructure.

This configuration allows for a user to use their personal user deviceto input sensitive personal information to receive prequalificationresults rather than using a dealer's device. In this regard, this avoidsany security risks of providing sensitive information on a third-partydevice. Furthermore, the system uses previously generatedprequalification results or pricing structures for a particular user orproduct to generate a subsequent pricing structure. By doing so, thesystem does not re-process data repeatedly and thusly, savescomputational resources.

FIG. 1 is a block diagram of an example environment in which systemsand/or methods described herein may be implemented. The environment mayinclude a central system 100, a seller device 110, a backend platform125, a cloud computing environment 132, a user device 140, a pricingdatabase 148, an applications database 146, and a network 130. Thedevices of the environment may be connected through wired connections,wireless connections, or a combination of wired and wirelessconnections.

In an example embodiment, one or more portions of the network 130 may bean ad hoc network, an intranet, an extranet, a virtual private network(VPN), a local area network (LAN), a wireless LAN (WLAN), a wide areanetwork (WAN), a wireless wide area network (WWAN), a metropolitan areanetwork (MAN), a portion of the Internet, a portion of the PublicSwitched Telephone Network (PSTN), a cellular telephone network, awireless network, a WiFi network, a WiMax network, any other type ofnetwork, or a combination of two or more such networks.

The backend platform 125 may include one or more devices configured tohost an architecture (e.g., architecture as shown in FIGS. 1-2) that isconfigured to provide prequalification results and financing optionsbased on decision-making policies of one or more lenders or financialinstitutions. The backend platform 125 may include a server or a groupof servers. In an embodiment, the backend platform 125 may be hosted ina cloud computing environment 132. It may be appreciated that thebackend platform 125 may not be cloud-based, or may be partiallycloud-based.

The central system 100, seller device 110, user device 140, pricingdatabase 148, and applications database 146 may include one or moredevices configured to interface with the backend platform 125. Thecentral system 100 may include a pre-qualification micro-service 102,eligibility micro-service 104, and pricing micro-service 106. The userdevice 140 may include a display 142 and a buyer application 144. Thedealer device 110 may include a seller application 118 and a display120. The buyer application 144 and seller application 118 may interfacewith the central system 100 to obtain loan offers for products that areintended to be purchased.

In an embodiment, the prequalification micro-service 102 may process, inparallel, the user's pre-qualification request with different lendersusing the user's personal information and the pre-qualificationinformation associated with each respective lender. Thepre-qualification information may be different for each lender. Forexample, each lender may require different thresholds of employmentinformation, salary, and/or credit scores.

In an embodiment, the eligibility micro-service 104 may generate producteligibility results. The product eligibility results may determinewhether a product is eligible for financing for a given lender and user.

In an embodiment, the pricing micro-service 106 may generate pricingoffers for loans for a given product based on the pre-qualification andproduct eligibility results.

In an embodiment, applications database 146 can store pre-qualificationinformation for users. The pre-qualification information may includedecisions on loan requests from various lenders. The pricing database148 may store information about loan offers for products based onfinancing information and information about the product.

The cloud computing environment 132 includes an environment thatdelivers computing as a service, whereby shared resources, services,etc. may be provided to the device 100 and/or the backend platform 125.The cloud computing environment 132 may provide computation, software,data access, storage, and/or other services that do not require end-userknowledge of a physical location and configuration of a system and/or adevice that delivers the services. The cloud computing system 132 mayinclude computing resources 126 a-d.

Each computing resource 126 a-d includes one or more personal computers,workstations, computers, server devices, or other types of computationand/or communication devices. The computing resource(s) 126 a-d may hostthe backend platform 125. The cloud resources may include computeinstances executing in the computing resources 126 a-d. The computingresources 126 a-d may communicate with other computing resources 126 a-dvia wired connections, wireless connections, or a combination of wiredor wireless connections.

Computing resources 126 a-d may include a group of cloud resources, suchas one or more applications (“APPs”) 126-1, one or more virtual machines(“VMs”) 126-2, virtualized storage (“VS”) 126-3, and one or morehypervisors (“HYPs”) 126-4.

Application 126-1 may include one or more software applications that maybe provided to or accessed by the user device 140 and seller device 110.In an embodiment, the buyer application 144 may execute locally on theuser device 140 and the seller application 118 may execute locally onthe seller device 110. Alternatively, the application 126-1 mayeliminate a need to install and execute software applications on theuser device 140 and seller device 110. The application 126-1 may includesoftware associated with backend platform 125 and/or any other softwareconfigured to be provided across the cloud computing environment 132.The application 126-1 may send/receive information from one or moreother applications 126-1, via the virtual machine 126-2.

Virtual machine 126-2 may include a software implementation of a machine(e.g., a computer) that executes programs like a physical machine.Virtual machine 126-2 may be either a system virtual machine or aprocess virtual machine, depending upon the use and degree ofcorrespondence to any real machine by virtual machine 126-2. A systemvirtual machine may provide a complete system platform that supports theexecution of a complete operating system (OS). A process virtual machinemay execute a single program and may support a single process. Thevirtual machine 126-2 may execute on behalf of a user (e.g., the userdevice 140 and seller device 110) and/or on behalf of one or more otherbackend platforms, and may manage the infrastructure of the cloudcomputing environment 132, such as data management, synchronization, orlong-duration data transfers.

Virtualized storage 126-3 may include one or more storage systems and/orone or more devices that use virtualization techniques within thestorage systems or devices of computing resource 126 a-d. With respectto a storage system, types of virtualizations may include blockvirtualization and file virtualization. Block virtualization may referto abstraction (or separation) of logical storage from physical storageso that the storage system may be accessed without regard to physicalstorage or heterogeneous structure. The separation may permitadministrators of the storage system flexibility in how administratorsmanage storage for end users. File virtualization may eliminatedependencies between data accessed at a file-level and location wherefiles are physically stored. This may enable optimization of storageuse, server consolidation, and/or performance of non-disruptive filemigrations.

Hypervisor 126-4 may provide hardware virtualization techniques thatallow multiple operations systems (e.g., “guest operating systems”) toexecute concurrently on a host computer, such as computing resource 126a-d. Hypervisor 126-4 may present a virtual operating platform to theguest operating systems and may manage the execution of the guestoperating systems multiple instances of a variety of operating systemsand may share virtualized hardware resources.

In an embodiment, a user of a user device 140 may desire to requestpre-qualification for a loan from one or more lenders for purchasing aproduct, while interacting with the seller. The user device 140 mayreceive an input to actuate a link. The link may be a hyperlink receivedby a messaging service or e-mail. Alternatively, the link may beembedded in a QR code in which user device 140 may actuate by extractingthe link embedded in the QR code, using a camera coupled to the userdevice 140. The link may be provided to the user by the seller. Forexample, the seller device 110 may transmit the link to the user device140 using a messaging service or through the seller application 118 tothe buyer application 144. In some embodiments, the user may be at aseller location and the seller may provide the user with a QR code orprovide the QR code for display at one or more locations or on one ormore mediums at the seller location. The link may include the seller'sidentifying information, such as a seller ID.

In response to actuating the link, a website may be launched on thedisplay 142 of the user device 140. In an embodiment, the website can belaunched within the buyer application 144. The user device 140 mayreceive input from a user for requesting prequalification for a loan forpurchasing a product. The input may be user information needed toprocess the prequalification request. For example, the user informationmay include full name, address, social security number, employmentinformation, salary, and/or the like. The user device 140 may transmitthe prequalification request including received user information and theseller ID included in the link, to the central system 100. Thisconfiguration allows for a user to use their personal user device 140 toinput sensitive personal information rather than using the seller'sdevice 110. This eliminates a security risk of the user inputtingsensitive information in using the seller's device 110.

In an embodiment, the user may have in login information associated withthe website. The user may be authenticated using their login andpassword information. Furthermore, in response to being authenticated, aportion of the user's information needed for the prequalificationrequest may be automatically populated on the website. For example, theuser's name and address may be automatically populated on the websiteupon the authentication of the user.

The central system 100 may receive the prequalification requestincluding received user information and the seller ID included in thelink. The central system 100 may transmit the user information andseller ID to the prequalification micro-service 102. Theprequalification micro-service 102 may identify the seller based on theseller ID. The prequalification micro-service 102 may process, inparallel, the user's pre-qualification request with one or moredifferent lenders using the user's personal information, the identifiedseller, and the pre-qualification information/policies associated witheach respective lender. The prequalification micro-service 102 mayprocess the prequalification request. Initially, the prequalificationmicro-service 102 may interface with one or more third-party creditbureaus to execute a soft pull of the user's credit score or creditprofile, using the user's personal information. Soft pulls are softcredit inquires that do not affect the user's credit score. Theprequalification micro-service 102 may generate prequalification resultsincluding decisions of prequalification of the user for one or more loancharacteristics from various lenders and the loan details orcharacteristics offered by each of the lenders, based on the user'spersonal information, soft pull, and methodologies/policies specific toeach lender. For example, the loan details may include the AnnualPercentage Rate (APR) or an interest rate stated as a yearly rate for aparticular loan duration and/or loan amount, or a maximum loan amountavailable to the user by the lender.

In an embodiment, the prequalification results may be generated specificto the current products/inventory being sold by the seller. For example,the prequalification microservice 102 may retrieve a seller's inventoryof products using the seller ID. The prequalification microservice 102may generate prequalification results for the user for the specificseller inventory of products.

In another embodiment, the prequalification results may be generatedbased on user preferences. For example, the prequalificationmicroservice 102 may retrieve user preferences regarding products. Theprequalification microservice 102 can generate prequalification resultsbased on the retrieved user preferences.

The central system 100 may route the prequalification results to theuser device 140. In an embodiment, the central system 100 may transmitthe prequalification results to the user device 140 be rendered on thebuyer application 144. In another embodiment, the central system 100 maytransmit the prequalification results to the user device 140 to berendered on the same website or web application on which the usertransmitted the prequalification request. The central system 100 mayalso transmit the prequalification results to the seller application118, based on the identified seller. For example, the centralapplication 100 may identify authentication details of a seller's ID.The central application 100 may transmit the prequalification results tothe seller application 118 only viewable to the seller using theappropriate authentication details. The prequalification results mayserve as a notification to the seller that the user is currently at theseller's location. The central application 100 may also store theprequalification results in the applications database 146.

The seller may execute the seller application 118 on the seller device110. The seller application 118 may receive user preferences forspecific products available for purchase by the seller and loanqualification status and details specific to the user for the specificproducts. For example, the seller application 118 may receive anindication regarding the first product which the user intends topurchase. The first product information may have been determined basedon user interaction with the buyer application 144 by receiving inputsassociated with one or more particular products or preferred productfeatures. In some embodiments, the user may have selected a particularfirst product associated with the seller (e.g. available in theinventory of a seller). The seller application may also receive inputfor a request for a pricing a first product based on user activity atthe seller location. The seller application 118 may transmit a requestfor pricing the first product including information regarding the firstproduct and the user to the central application 100. The request may bean HTTP request. The central system 100 may retrieve the user'sprequalification results from the applications database 146. The centralsystem 100 may transmit the information regarding the first product andthe user's prequalification results to the eligibility micro-service104. The eligibility micro-service 104 may determine whether the firstproduct is eligible for financing for one or more lenders, or eachlender which prequalified the user for a loan in the prequalificationresults.

The central system 100 may transmit information regarding the lenderswhich prequalified the user for a loan, and information regardinglenders which deem the first product eligible for a loan, to the pricingmicro-service 106. The pricing micro-service 106 may generate pricingstructure(s) based on the information regarding the first product, theuser's prequalification results, and information regarding lenders thatdeem the first product eligible for a loan. The pricing micro-service106 may ensure that the loan details provided to the user in theprequalification results are the same loan details applied forgenerating the one or more pricing structures. Each pricing structuremay include loan details for the first product, for each lender. Theloan details may include APRs, expected monthly payments, loan amounts,loan terms, and/or the like. The central system 100 may store eachpricing structure in the pricing database 148. The central system 100may transmit the pricing results to the seller application 118. Theseller may repeat this process for any other product available forpurchase.

Once a user has determined to initiate a purchase process for a product,the seller may use the seller application 118 to transmit a purchaserequest for a specified product for a user. The seller application 118may transmit the purchase request of the specified product for a user tothe central system 100. The central system 100 may determine whether thespecified product was priced at a previous time by querying the pricingdatabase 148. The central system 100 may retrieve a pricing structure(for each of one or more lenders) for the specified product and userfrom the pricing database 148. The central system 100 may determinewhether the pricing structure was generated within a given time period.In response to determining the pricing structure was generated withinthe given time period, the central system 100 may transmit the purchaserequest for the specified product and previously generated pricingstructure to the pricing micro-service. The pricing micro-service 106may interface with third-party credit bureaus to execute a hard creditpull for the user. The pricing micro-service 106 may use the previouslygenerated pricing structure to build a loan offer (for each of one ormore lenders) in a final pricing structure for the user for thespecified product. The pricing micro-service 106 may ensure the pricingdetails provided in the previously generated pricing structure are thesame as the final pricing structure. The pricing micro-service 106 mayuse each of the one or more lenders' methodologies in generating theloan offer. In the event the specified product has not been priced forthe user or was not priced within the given time period, the centralsystem 100 may transmit the purchase request without any previouslygenerated pricing structure. In an embodiment, the purchase request mayalso include a desired lender which prequalified the user. The loanoffer may be generated for the desired lender. Alternatively, multipleloan offers may be generated for various lenders.

As a non-limiting example, the seller may be an automobile dealership,the products may be automobiles and the type of loan may beauto-financing.

FIG. 2 is block diagrams illustrating an architecture implementing thesystem described herein, according to an embodiment. The architecturemay include a buyer application 144, a seller application 118, a DigitalRetailer 204, Buy/Sell API 210, and a multi-lender layer 212. TheBuy/Sell API 210 may reside in an experience layer 208. The Buy/Sell API210 may facilitate communication between the buyer application 144,seller application 118, and/or Digital Retailer 204 and the multi-lenderlayer 212. The buyer application 144 may be used by a user to obtainprequalification results as described with respect to FIG. 1. Forexample, in response to actuating the link or QR code, the sellerapplication 118 may interface with the multi-lender layer 212 to obtainprequalification results. The seller application 118 may be used to viewprequalified users as described with respect to FIG. 1. The DigitalRetailer 204 may be a seller's website including a link to interfacewith the multi-lender layer to generate prequalification results andobtain loan pricing information. The architecture may further include alender portal 220 through which lenders may access the multi-lenderlayer.

The multi-lender layer 212 may include an API Passthru 214 and a vault216. The API Passthru 214 may be an API Gateway. The API Passthru 214may be responsible for request routing, composition, and protocoltranslation. The lender portal 220 may also reside in the multi-lenderlayer 212. The vault 216 may include micro-processes such asprequalification 102, product eligibility 104, and pricing 106. Thevault 216 may also include an encrypted logs 222 and a lenderconfidential repository 221. The encrypted logs 222 may be a datarepository.

In an embodiment, a plurality of lenders 226 may interface with thelender portal 220 to upload and/or communicate information or policiesassociated with their prequalification, product eligibility, andpricing, to the vault 216. The information may include rules,algorithms, equations, restrictions, and/or the like, which govern theprocess of offering users loans for automobiles at determined prices.The information may be stored in the lender confidential repository 221.In an embodiment, the information received and stored in an encryptedformat. Alternatively, the information may be received in an encryptedformat. The vault 216 may decrypt the information using the encryptionservice 218 and store the information in a decrypted format.

As lenders 226 may upload proprietary information into the vault 216,the vault 216 may provide a secure environment in which the proprietaryinformation may not be visible to anyone else (including theadministrator of the multi-lender architecture) other than the lender.The vault 216 may reside in a jailed, self-contained network, configuredto receive and transmit data in an encrypted format. In thisself-contained network, lenders may manage their separate accounts. Eachlender can securely manage its loan eligibility criteria, rules, filingpolicies, and/or the like. Lenders 226 may view their data inside thevault 216 and may not view data associated with other lenders 226. Thedata inside the vault 216 may not be visible to users through the buyerapplication 144, seller application 118, or Digital retailer 204.

In an embodiment, buyer application 144 may be an application configuredto search for products and procure pricing structure for a loan fromvarious lenders, executing on a customer's device. Seller application118 may be an application configured for procuring pricing structure fora loan for a particular user from one or more of various lenders,executing on a seller's device. The loan can be one or more of: anautomobile loan, a mortgage, unsecured personal loans, secured personalloans, debt consolidation loans, or variable-interest loans. The productfor sale can be a house, car, motorcycle, recreational vehicle (RV),aircraft, boat, and/or the like.

As an example, a user may interface with buyer application 144 or sellerapplication 118 in an attempt to obtain a pricing structure for a loanfor an automobile. In one embodiment, the buyer application 144 orseller application 118 application may each render different graphicaluser interfaces (GUIs) configured to receive input from the user whichmay be transmitted to the multi-lender layer for further processing, toobtain pricing structure for a loan for an automobile. The inputinformation may be transmitted to the multi-lender layer 212 through theBuy/Sell API 210. Information may be communicated from the multi-lenderlayer 212 to buyer application 144, seller application 118, or Digitalretailer 204 through the Buy/Sell API 210, to be rendered in therespective GUI.

The vault 216 may process the prequalification, product eligibility, andpricing structure associated with building a loan offer for one or moreof multiple lenders, in parallel, using proprietary information providedby each lender. As described above, the vault 216 may be a jailedenvironment, such that, while the lenders 226 may provide theirproprietary information for building a loan offer to be stored in thevault 216, the lenders or users may not access or view other lenders'proprietary information for building a loan offer. This configurationprovides a technical advantage over conventional systems because thisconfiguration can generate multiple loan offers from various lenders inparallel using each lender's proprietary information while maintaining asecure jailed environment restricting access or visibility to thelenders' proprietary information.

As an example, in response to actuating the link, a website forobtaining prequalification results may be launched within the buyerapplication 144. Alternatively, the website may be launched in aseparate browser or web application. Furthermore, the user may interfacewith the buyer application 144 to obtain a pricing structure for a loanfor an automobile. The buyer application 144 may present a selection forrequesting to get pre-qualified. In response to the user selecting therequest for getting pre-qualified, the buyer application 144 may receiveinput associated with personal information of the user (e.g., name,address, asset information, salary, employment information, socialsecurity number, and/or the like). In one embodiment, the buyerapplication 144 transmits the encrypted personal information andprequalification request to the multi-lender layer 212, via the Buy/SellAPI 210, using Hypertext Transfer Protocol Secure (HTTPS). In anembodiment, the buyer application 144 may encrypt the personalinformation and prequalification request and transmit the encryptedpersonal information and prequalification request to the multi-lenderlayer 212, via the Buy/Sell API 210. In another embodiment, portions ofthe personal information may be encrypted by the buyer application 144,such as the social security number (SSN).

The Buy/Sell API 210 can determine which lenders can provide automobileloans based on the personal information. For example, the Buy/Sell API210 may determine a set of lenders that can provide automobile loansbased on the personal information provided by the user and based on oneor more rules specific to each of one or more lenders. The Buy/Sell API210 can generate a prequalification request for each lender in the setof lenders and transmit each request to the multi-lender layer 212.

The API Passthru 214 may receive the input from the Buy/Sell API 210, inthe multi-lender layer 212. In some embodiments, the input may beencrypted. The API Passthru 214 may forward the personal informationalong with the prequalification requests for each lender of the set oflenders to the vault 216. The vault 216 may execute the prequalificationmicro-service 102. The prequalification micro-service 102 may interfacewith one or more third-party credit bureaus to retrieve user creditinformation using the decrypted personal information associated with theuser. The prequalification micro-service 102 may request the third partycredit bureaus to initiate a soft pull. A single soft pull may berequested regardless of the number of lenders in the set of lenders.Soft pulls are soft credit inquires that do not affect the user's creditscore. The prequalification micro-service 102 may retrieveprequalification information associated with each of the set of lendersfrom the lender confidential repository 221. The lender confidentialinformation may include rules on how each lender processesprequalification.

The prequalification micro-service 102 may process, in parallel, theuser's prequalification request for each of the set of lenders using theuser's personal information and the prequalification informationassociated with each respective lender. As described above, theprequalification may be different for each lender. For example, eachlender may require different thresholds of employment information,salary, and/or credit scores.

The prequalification micro-service 102 may generate prequalificationresults, in response to processing the user's prequalification requestfor each of the multiple lenders. The prequalification results mayinclude a subset of lenders from the set of lenders which havepre-qualified the user for an automobile loan based on the personalinformation of the user and the prequalification information associatedwith the respective lender. The prequalification results can include adecision on whether the lender has pre-qualified a user for anautomobile loan. In an embodiment, the prequalification results may alsoinclude information associated with the loan such as a range of possibleAnnual Percentage Rates (APRs) and terms and conditions of the loans ora maximum amount of a loan. In an embodiment, the vault 216 may transmitthe prequalification results to the buyer application 144 unencrypted.Alternatively, the vault 216 may encrypt the prequalification resultsusing the encryption service 201 and transmit the encryptedprequalification results to the API Passthru 214 The API Passthru 214may forward the prequalification results to the Buy/Sell API 210. TheBuy/Sell API 210 may transmit the prequalification results to the buyerapplication 144. In the event the prequalification results areencrypted, the buyer application 144 can decrypt the encryptedprequalification results. The buyer application 144 can render theprequalification results on the buyer application 144 GUI.

As described above, a user can use obtain prequalification results byactuating a link or QR code or through the buyer application 114. In theevent, the user actuates the link or QR code to obtain prequalificationresults through a website and the user has already generatedprequalification results using the buyer application 114, theprequalification micro-service 102 can retrieve the prequalificationresults for the user based on their login and password information forproducts sold by the seller where the user actuated the link or QR code.The retrieved prequalification results can be rendered in the buyerapplication 144.

Continuing from the earlier example, subsequent to the prequalificationresults being rendered on the GUI of the buyer application 144, thebuyer application 144 may receive a selection of a vehicle intended forpurchase, from a user. The buyer application 144 may transmit theinformation associated with the selected vehicle (e.g., make, model,mileage, year, dealership, and/or the like) to the multi-lender layer212, via the Buy/Sell API 210.

The API Passthru 214 may receive the information associated with theselected vehicle of the user from the Buy/Sell API 210, in themulti-lender layer 212. The API Passthru 214 may forward the informationassociated with the selected vehicle to the vault 216. The vault 216 maydecrypt the encrypted information associated with the selected vehicle,using the encryption service 218. The vault 216 may execute the producteligibility micro-service 104. The product eligibility micro-service 104may retrieve product eligibility information associated with the lendersincluded in the subset of lenders, from the lender confidentialrepository 221. The product eligibility micro-service 104 may determine,in parallel, whether the selected vehicle is eligible for an automobileloan from a given lender based on the information associated with theselected vehicle and information associated with product eligibility foreach of the respective lenders. The information associated with producteligibility may be different for each lender. For example, each lendermay have different requirements for make, model, year, mileage, price,and/or the like. In this regard, the product eligibility 104 maydetermine certain vehicles are not eligible for automobile loans fromgiven lenders.

The product eligibility micro-service 104 may generate producteligibility results. The product eligibility results may include one ormore lenders from the subset of lenders, for which the producteligibility micro-service 104 determined the selected vehicle iseligible for an automobile loan. The API Passthru 214 may forward theproduct eligibility results to the Buy/Sell API 210. The buyerapplication 144 may render the decrypted product eligibility results onthe buyer application 144 GUI.

Continuing with the earlier example, subsequent to the producteligibility results being rendered on the GUI of the buyer application144, the buyer application 144 may receive a request to build a loanoffer for a selected vehicle, from a user. The request may includeinformation associated with the desired loan, such as the price of aselected vehicle, down payment amount, loan amount, tax amount, dealerfees, service contract, GAP, and/or the like. The buyer application 144may encrypt the information associated with the request for building anoffer and transmit the information associated with the request forbuilding an offer to the multi-lender layer 212, via the Buy/Sell API210. Alternatively, the Buy/Sell API 210 may encrypt the informationassociated with the request for building an offer and transmit theencrypted information associated with the request for building an offerto the multi-lender layer 212. In yet another example, the buyerapplication 144 may transmit the request including the information tothe multi-lender layer 212, using the Buy/Sell API 210. The Buy/Sell API210 may determine that the user is eligible for a loan from one or morelenders, based on the prequalification results and the producteligibility results. The Buy/Sell API 210 can generate pricing offerrequests for each of the one or more lenders and transmit the requeststo the multi-lender layer 212.

The API Passthru 214 may receive the information associated with therequest for building an offer from the Buy/Sell API 210 and the requestsfor each of the one or more lenders, in the multi-lender layer 212. TheAPI Passthru 214 may forward the information associated with therequests for each of the or more lenders for building an offer to thevault 216. The vault 216 may execute the pricing micro-service 106. Thepricing micro-service 106 may retrieve pricing structure informationassociated with each lender of the one or more lenders, from the lenderconfidential repository 221. The pricing micro-service 106 may useBayesian regression algorithms, decision trees, pricing girds or variousequations for pricing for a loan offer. The pricing structure may alsoprovide sources for retrieving certain information. For example, alender may need to use the prequalification results and/or producteligibility results. The lender may indicate to the pricingmicro-service to retrieve the prequalification results and/or producteligibility results. Alternatively, or in addition to, the pricingstructure may include instructions to retrieve information fromthird-party vendors. Accordingly, the pricing micro-service 106 mayretrieve the information using the third-party vendors. The pricingmicro-service 106 may process and build, in parallel, a loan offer basedon the information associated with the request for building an offer,for each of the one or more lenders using information associated withpricing for each of the respective lenders. Additionally, each lendermay use a different methodology for calculating pricing for a loanoffer.

The pricing micro-service 106 may generate pricing structures forautomobile loans from various lenders. The pricing structures mayinclude loan amounts, interest rates, and terms and conditions of theautomobile loan. The vault 216 may encrypt the offers using theencryption service 218 and transmit the encrypted vehicle offers to theAPI Passthru 214. The API Passthru 214 may forward the encrypted offersto the Buy/Sell API 210. In an example, the Buy/Sell API 210 may decryptthe encrypted offers and interface with the buyer application 144 torender the decrypted offers on the buyer application 144 GUI.Alternatively, the Buy/Sell API 210 may transmit the encrypted offers tothe buyer application 144. Buyer application 144 can decrypt theencrypted offers and render the decrypted offers on the buyerapplication 144 GUI.

The architecture may also include an analytic aggregator 224. Theanalytic aggregator may be embodied as a micro-service residing in thevault 216. The analytic aggregator 224 may capture all of the datagenerated in the vault 216 for each user (e.g., prequalificationresults, product eligibility results, and offers) for each lender andstore the captured data in the encrypted logs 222. The captured data maybe encrypted in a format specific to a given lender, such that, a lendermay only decrypt data from the encrypted logs 222. A lender may downloaddata logs from the encrypted logs 222 specific to the lender itself.

In an embodiment, the architecture may be associated with a financialinstitution (e.g., bank or lender). As an example, the administrator ofthe architecture may be a financial institution. The financialinstitution may use its own lending platform 232. The lending platform232 may include a loan origination system 234. Buyer application 144 maycommunicate back and forth with the loan origination system 234 of thelending platform 232 to generate a loan offer from the financialinstitution, via the Buy/Sell API 210 and the API Passthru 214 in themulti-lender layer 212. Buyer application 144 may communicate back andforth with the loan origination system 234 to generate a loan offer fromthe financial institution, in parallel with the micro-processes (e.g.,prequalification 102, product eligibility 104, and pricing 106)generating loan offers from various lenders in the vault 216. The loanoffers from the financial institution may be presented alongside theloan offers from the other lenders on the GUI of the buyer application144.

In an embodiment, the architecture may include one or more third-partyAPI 228 including a third-party loan origination system 230. In theevent, a lender does not upload information associated withprequalification, product eligibility, and pricing for processing withinvault 216 as described above, the vault 216 is bypassed and thethird-party loan origination system 230 may generate a loan offer forthe lender. The third-party loan origination system 230 may be an APIprovided by a lender for generating the loan offer using the lender'sAPI. The third-party loan origination system 230 may communicate backand forth with the buyer application 144, via the Buy/Sell API 210 andthe API Passthru 214 in the multi-lender layer 212, to generate a loanoffer. Buyer application 144 may communicate back and forth with thethird-party loan origination system 230 of the third-party API 228 togenerate a loan offer from the third-party lender, in parallel with themicro-processes (e.g., prequalification 102, product eligibility 104,and pricing 106) generating loan offers from various lenders in thevault 216 and/or lending platform 232.

In one embodiment, a Digital retailer 204 (i.e., a third-party system)may be embodied as a web domain associated with an automobiledealership. The Digital retailer 204 may render a hyperlink. Thehyperlink is different than the link or QR code discussed above. Thishyperlink may generate an interface embedded in the web domain. Theinterface may be used to communicate with the multi-lender layer 212.The interface may be used to receive prequalification results. TheDigital retailer 204 may interface with the multi-lender layer 212 usingthe hyperlink.

In an embodiment, the seller application 118 may be executable on adevice of an automobile dealership (i.e., dealer device). The sellerapplication 118 may interface with the multi-lender layer 212 todetermine prequalification, product eligibility, and pricing asdescribed with respect to buyer application 144. The seller application118 may transmit a link directed to the multi-layer lender to initiate aprequalification request to a user device. As an example, the sellerapplication 118 may transmit the link via Short Messaging Service (SMS)or e-mail message to the user device. The user may transmit aprequalification request using the link as described above.

FIG. 3 is a block diagram illustrating an expanded view of the Buy/SellAPI 210 according to some embodiments. The Buy/Sell API 210 may residein the experience layer of the multi-lender architecture. The Buy/SellAPI 210 may be used to interface between clients such as buyerapplication 144, seller application 118, and Digital retailer 204, andthe multi-lender layer.

The experience layer 208 may further include a marketplace module 301,pricing module 302, an application module 303, an offer module 304, adealer module 305, and a pricing cache 306. The experience layer 208 mayuse the market place module 301, pricing module 302, the applicationmodule 303, offer module 304, dealer module 305, and pricing cache 306to provide consistent and reliable pricing structure to a user bystoring the pricing, prequalification, and applications submitted by auser for a specified period of time.

The application module 303 may route prequalification requests to theprequalification micro-service and may receive the prequalificationresults. The application module 303 may store prequalification resultsin the prequalification database 146. The prequalification results maybe correlated to various users. The pricing module 302 may route thepricing request to the pricing micro-service and receive the pricingstructures from the pricing micro-service. The pricing module 304 maystore pricing structures generated for a given product in the pricingdatabase 148. The pricing structures can be correlated to a user. In anembodiment, the pricing cache 306 may store pricing structures generatedfor a given product for a particular user for a short period of time(e.g., single session). The offers module 304 may route a purchaserequest for a given product for a user to the pricing micro-service. Theoffers module 304 may store final pricing structures offered to a userin the offers database 308.

The marketplace module 301 may store information associated with lendersand products. The information the marketplace module 301 may update in(near) real-time. The market place module 301 may include a repository310. For example, a user may apply for a loan for a product. TheBuy/Sell API 210 may filter out lenders from the marketplace which maynot provide loans for the product based on the personal information ofthe user or the product itself as the user provides information. If theuser is attempting to generate a price for a loan for a luxury car and agiven lender does not provide loans for luxury cars, the lender isfiltered out from the marketplace. Additionally, as the application forthe loan is processed, each time a lender rejects or approves the loan,the marketplace module 301 may update the repository 310. Furthermore,based on the lenders for which the loans are being processed, theBuy/Sell API 210 can filter out the ineligible products from themarketplace module 301 which may not be eligible for a loan.

The seller module 305 may manage the information associated withdifferent dealers. For example, seller application 118 may communicatewith the dealer module 305 to retrieve dealer specific information frommodule 305. The dealer specific information may include dealerrequirements for purchasing automobiles, partnerships with lenders andvendors, dealer inventory, and/or the like.

FIGS. 4A-4D illustrate screens displayed on a graphical user interfaceof a user device to obtain prequalification results according to someembodiments. With reference to FIG. 4A, a user device 140 may scan QRcode 400 using a camera or scanning device. The QR code 400 may belocated at a seller's location. For example, as shown in FIG. 4A, the QRcode is located on a badge of an employee at the seller's location. Alink may be embedded in the QR code 400. In response to actuating thelink, the user device may be routed to a website rendering screen 402.The screen 402 may be a welcome screen for initiating a prequalificationrequest for the user.

With reference to FIG. 4B, in response to the user proceeding fromscreen 402, screen 404 may be rendered on the user device 140. Screen404 may include an option to input login information if the user alreadyhas login information. Alternatively, screen 404 also displays an optionto continue as a guest. In response to either logging in or continuingas a guest, screen 406 may be rendered on the user device 140.

Screen 406 may include input boxes for inputting the user's personalinformation. The information may include the name and addressinformation. In an embodiment, in response to logging in, the name andaddress information may be automatically populated on screen 406.

With reference to FIG. 4C, in response to inputting personalinformation, screen 408 may be rendered on the user device 140. Screen408 may include further questions about the user. For example, if theuser is at a dealership, screen 408 may include questions whether theuser wants to trade-in a vehicle. Once the user has input all thenecessary information, the user may select a button rendered on the userdevice 140 to transmit the prequalification request. Theprequalification result may be processed for the user as describedabove, with respect to FIG. 1.

With reference to FIG. 4D, in response to processing theprequalification request, a prequalification result may be generated.The prequalification result may be rendered on screen 410. Screen 410may render the lenders which prequalified the user for a loan as well asinformation about the seller. Screen 410 may also include a message thatthe prequalification results have also been routed to the seller.

FIG. 5 is a screen 500 displayed on a graphical user interface of aseller device 110 according to some embodiments. As indicated above, theprequalification result of a user may be routed to the seller device110. Screen 500 may include prequalification results for differentusers. Screen 500 may include when the prequalification result wasreceived, a reference id, user name, user type, lead source, status, andaction. The user type may be a lead (e.g., sales lead). The lead sourcemay be walk-in, pre-approval, auto navigator, or the like. The statusmay indicate the prequalification status of the user. If the user hasbeen prequalified for a loan, the status may be prequalificationapproved. The action may be an open deal jacket action, view creditreport action, or the like. In the event, the user has been prequalifiedfor a loan, the action may be the open deal jacket action. The open dealjacket action may be a link to start a deal on a product for the user.In the event, the user has not been able to prequalify for a loan, theaction may be view credit report. The open deal jacket and view creditreport may be links that may direct the seller's device 110 to anotherwebsite.

FIG. 6 is an example flow for obtaining prequalification resultsaccording to some embodiments. Method 600 can be performed by processinglogic that can comprise hardware (e.g., circuitry, dedicated logic,programmable logic, microcode, etc.), software (e.g., instructionsexecuting on a processing device), or a combination thereof. It is to beappreciated that not all steps can be needed to perform the disclosureprovided herein. Further, some of the steps can be performedsimultaneously, or in a different order than shown in FIG. 6, as will beunderstood by a person of ordinary skill in the art.

Method 600 shall be described with reference to FIG. 1. However, method600 is not limited to that example embodiment

In operation 602, a central system may launch a website on a user devicein response to the actuation of a link associated with a seller. Thelink may be a hyperlink to a website or a QR code. The seller mayprovide this link through email or text message. Alternatively, the QRcode may be displayed at a seller's location (e.g., retail store, cardealership, or the like). The link may include the seller's ID. Thewebsite may include a request for user information. The website mayreceive user input associated with the user information. The websitelink may include a seller identification information. The website maytransmit a prequalification request for a loan for the user includingthe user information and the seller identification information.

In operation 604, the central system may receive the prequalificationrequest including the user information. As described above, theprequalification request may include information about and the seller'sidentification information.

In operation 606, the central system may identify the seller using theseller's identification information. As described above, the seller's IDmay be included in the actuated link. The central system may retrieveseller information using the seller ID. For example, the central systemmay retrieve the seller's inventory and the seller's preferenceregarding financing their products. The preferences may include certainlenders that the seller does not work with or does not prefer. Thepreferences may also include information that the seller is likely to beopen to adjusting the final price of a product with the purchase ofbackend services.

In operation 608, the central system may interface with third-partycredit systems to execute a soft credit inquiry to generate theprequalification requests, using the user information.

In operation 610, the central system may generate a prequalificationresult for the user, specific to the identified seller. Theprequalification result is generated by the prequalificationmicroservice. The prequalification result may generate theprequalification result specific to the inventory of the seller as wellas the seller's preferences.

In operation 612, the central system may route the prequalificationresult to a seller device based on the seller identificationinformation. The prequalification result may also be transmitted to thewebsite. The website may render the prequalification result and theseller's current inventory.

In operation 614, the central system may receive information about aspecified product embedded in a request protocol. The information may bereceived from the seller device or the user device. The eligibilitymicroservice may determine whether the product is eligible for purchase.

In operation 616, the central system may generate a pricing structurefor the specified product based on the prequalification results. Thepricing structure is generated by the pricing microservice for thespecified product.

In operation 618, the central system may receive a purchase request forthe specified product. The purchase request may be received from theseller device.

In operation 620, the central system may confirm that the purchaserequest was received within a specified time period of theprequalification request or a previous pricing request.

In operation 622, the central system may correlate the purchase requestwith the prequalification request based on the purchase request beingfor the user for which the prequalification request was processed.

In operation 624, the central system may interface with a third partycredit system to execute a hard credit inquiry.

In operation 626, the central system may generate a second pricingstructure for the specified product. The data included in the secondpricing structure based on the purchase request may be the same as dataincluded in the first pricing structure generated based on theprequalification result.

FIG. 7 is a block diagram of example components of device 700. One ormore computer systems 700 may be used, for example, to implement any ofthe embodiments discussed herein, as well as combinations andsub-combinations thereof. Computer system 700 may include one or moreprocessors (also called central processing units, or CPUs), such as aprocessor 704. Processor 704 may be connected to a communicationinfrastructure or bus 706.

Computer system 700 may also include user input/output device(s) 703,such as monitors, keyboards, pointing devices, etc., which maycommunicate with communication infrastructure 706 through userinput/output interface(s) 702.

One or more processors 704 may be a graphics processing unit (GPU). Inan embodiment, a GPU may be a processor that is a specialized electroniccircuit designed to process mathematically intensive applications. TheGPU may have a parallel structure that is efficient for parallelprocessing of large blocks of data, such as mathematically intensivedata common to computer graphics applications, images, videos, etc.

Computer system 700 may also include a main or primary memory 308, suchas random access memory (RAM). Main memory 308 may include one or morelevels of cache. Main memory 308 may have stored therein control logic(i.e., computer software) and/or data.

Computer system 700 may also include one or more secondary storagedevices or memory 710. Secondary memory 710 may include, for example, ahard disk drive 712 and/or a removable storage device or drive 714.

Removable storage drive 714 may interact with a removable storage unit718. Removable storage unit 718 may include a computer-usable orreadable storage device having stored thereon computer software (controllogic) and/or data. Removable storage unit 718 may be program cartridgeand cartridge interface (such as that found in video game devices), aremovable memory chip (such as an EPROM or PROM) and associated socket,a memory stick and USB port, a memory card and associated memory cardslot, and/or any other removable storage unit and associated interface.Removable storage drive 714 may read from and/or write to removablestorage unit 718.

Secondary memory 710 may include other means, devices, components,instrumentalities or other approaches for allowing computer programsand/or other instructions and/or data to be accessed by computer system700. Such means, devices, components, instrumentalities or otherapproaches may include, for example, a removable storage unit 722 and aninterface 720. Examples of the removable storage unit 722 and theinterface 720 may include a program cartridge and cartridge interface(such as that found in video game devices), a removable memory chip(such as an EPROM or PROM) and associated socket, a memory stick and USBport, a memory card and associated memory card slot, and/or any otherremovable storage unit and associated interface.

Computer system 700 may further include a communication or networkinterface 724. Communication interface 724 may enable computer system700 to communicate and interact with any combination of externaldevices, external networks, external entities, etc. (individually andcollectively referenced by reference number 728). For example,communication interface 724 may allow computer system 700 to communicatewith external or remote devices 728 over communications path 726, whichmay be wired and/or wireless (or a combination thereof), and which mayinclude any combination of LANs, WANs, the Internet, etc. Control logicand/or data may be transmitted to and from computer system 700 viacommunication path 726.

Computer system 700 may also be any of a personal digital assistant(PDA), desktop workstation, laptop or notebook computer, netbook,tablet, smartphone, smartwatch or other wearables, appliance, part ofthe Internet-of-Things, and/or embedded system, to name a fewnon-limiting examples, or any combination thereof.

Computer system 700 may be a client or server, accessing or hosting anyapplications and/or data through any delivery paradigm, including butnot limited to remote or distributed cloud computing solutions; local oron-premises software (“on-premise” cloud-based solutions); “as aservice” models (e.g., content as a service (CaaS), digital content as aservice (DCaaS), software as a service (SaaS), managed software as aservice (MSaaS), platform as a service (PaaS), desktop as a service(DaaS), framework as a service (FaaS), backend as a service (BaaS),mobile backend as a service (MBaaS), infrastructure as a service (IaaS),etc.); and/or a hybrid model including any combination of the foregoingexamples or other services or delivery paradigms.

Any applicable data structures, file formats, and schemas in computersystem 700 may be derived from standards including but not limited toJavaScript Object Notation (JSON), Extensible Markup Language (XML), YetAnother Markup Language (YAML), Extensible Hypertext Markup Language(XHTML), Wireless Markup Language (WML), MessagePack, XML User InterfaceLanguage (XUL), or any other functionally similar representations aloneor in combination. Alternatively, proprietary data structures, formatsor schemas may be used, either exclusively or in combination with knownor open standards.

In some embodiments, a tangible, non-transitory apparatus or article ofmanufacture comprising a tangible, non-transitory computer useable orreadable medium having control logic (software) stored thereon may alsobe referred to herein as a computer program product or program storagedevice. This includes, but is not limited to, computer system 700, mainmemory 308, secondary memory 710, and removable storage units 718 and722, as well as tangible articles of manufacture embodying anycombination of the foregoing. Such control logic, when executed by oneor more data processing devices (such as computer system 700), may causesuch data processing devices to operate as described herein.

Embodiments of the present disclosure have been described above with theaid of functional building blocks illustrating the implementation ofspecified functions and relationships thereof. The boundaries of thesefunctional building blocks have been arbitrarily defined herein for theconvenience of the description. Alternate boundaries may be defined solong as the specified functions and relationships thereof areappropriately performed.

The foregoing description of the specific embodiments will so fullyreveal the general nature of the disclosure that others may, by applyingknowledge within the skill of the art, readily modify and/or adapt forvarious applications such specific embodiments, without undueexperimentation, without departing from the general concept of thepresent disclosure. Therefore, such adaptations and modifications areintended to be within the meaning and range of equivalents of thedisclosed embodiments, based on the teaching and guidance presentedherein. It is to be understood that the phraseology or terminologyherein is for the purpose of description and not of limitation, suchthat the terminology or phraseology of the present specification is tobe interpreted by the skilled artisan in light of the teachings andguidance.

The breadth and scope of the present disclosure should not be limited byany of the above-described exemplary embodiments but should be definedonly in accordance with the following claims and their equivalents.

1. A method for retrieving prequalification information, the method comprising: launching, by one or more computing devices, a website for display on a user device in response to the user device actuating a link associated with a seller, the website including a request for user information; receiving, by the one or more computing devices, a prequalification request including the user information from the user device; identifying, by the one or more computing devices, the seller based on seller identifying information embedded in the actuated link; generating, by the one or more computing devices, a prequalification result for the user, specific to the seller using a decisioning service independent of the seller; routing, by the one or more computing devices, the prequalification result from the decisioning service to the user device and a seller device based on the seller identifying information; receiving, by the one or more computing devices, information about a specified product embedded in a request protocol; generating, by the one or more computing devices, a first pricing structure for the specified product based on the prequalification results; receiving, by the one or more computing devices, a purchase request for the specified product; correlating, by the one or more computing devices, the purchase request with the prequalification request based on the purchase request being for the user for which the prequalification request was processed; and generating, by the one or more computing devices, a second pricing structure for the specified product, wherein data included in the second pricing structure is the same as data included in the first pricing structure.
 2. The method of claim 1, further comprising confirming, by the one or more computing devices, the purchase request was received within a specified time period of the prequalification request.
 3. The method of claim 1, further comprising interfacing, by the one or more computing devices, with a third-party credit system to execute a soft credit inquiry to generate the prequalification results, using the user information.
 4. (canceled)
 5. The method of claim 1, wherein the purchase request is received from the seller device.
 6. The method of claim 1, further comprising identifying, by the one or more computing devices, the seller device by using the seller identification information to retrieve the seller's authentication details of a seller application executing on the seller device.
 7. The method of claim 1, further comprising interfacing, by the one or more computing devices, with a third party credit system to execute a hard credit inquiry in response to the purchase request.
 8. A system for retrieving prequalification information, the system comprising: a memory; a processor in communication with the memory, the processor configured to: launch a website for display on a user device in response to the user device actuating a link associated with a seller, the website including a request for user information; receive a prequalification request including the user information from the user device; identify the seller based on seller identifying information embedded in the actuated link; generate a prequalification result for the user, specific to the seller using a decisioning service independent of the seller; route the prequalification result from the decisioning service to the user device and a seller device based on the seller identifying information; receive information about a specified product embedded in a request protocol; generate a first pricing structure for a specified product based on the prequalification results; receive a purchase request for the specified product; correlate the purchase request with the prequalification request based on the purchase request being for the user for which the prequalification request was processed; and generate a second pricing structure for the specified product, wherein data included in the second pricing structure is the same as data included in the first pricing structure.
 9. The system of claim 8, wherein the processor further configured to confirm the purchase request was received within a specified time period of the prequalification request.
 10. The system of claim 8, wherein the processor further configured to interface with a third-party credit system to execute a soft credit inquiry to generate the prequalification results, using the user information.
 11. (canceled)
 12. The system of claim 8, wherein the purchase request is received from the seller device.
 13. The system of claim 8, wherein the processor further configured to identify the seller device by using the seller identification information to retrieve the seller's authentication details of a seller application executing on the seller device.
 14. The system of claim 8, wherein the processor further configured to interface with a third party credit system to execute a hard credit inquiry in response to the purchase request.
 15. A non-transitory computer-readable medium storing instructions that when executed by one or more processors of a device cause the one or more processors to perform operations comprising: launching a website for display on a user device in response to the user device actuating a link associated with a seller, the website including a request for user information; a prequalification request including the user information from the user device; identifying the seller based on seller identifying information embedded in the actuated link; generating a prequalification result for the user, specific to the seller using a decisioning service independent of the seller; routing the prequalification result from the decisioning service to the user device and a seller device based on the seller identifying information; receiving information about a specified product embedded in a request protocol; generating a first pricing structure for a specified product based on the prequalification results; receiving a purchase request for the specified product; correlating the purchase request with the prequalification request based on the purchase request being for the user for which the prequalification request was processed; and generating a second pricing structure for the specified product, wherein data included in the second pricing structure is the same as data included in the first pricing structure.
 16. The non-transitory computer-readable medium of claim 15, the operations further comprising confirming the purchase request was received within a specified time period of the prequalification request.
 17. The non-transitory computer-readable medium of claim 15, the operations further comprising interfacing with a third-party credit system to execute a soft credit inquiry to generate the prequalification results, using the user information.
 18. (canceled)
 19. The non-transitory computer-readable medium of claim 15, wherein the purchase request is received from the seller device.
 20. The non-transitory computer-readable medium of claim 15, the operations further comprising the seller device by using the seller identification information to retrieve the seller's authentication details of a seller application executing on the seller device. 